1. Field
The present disclosure relates to data transmission control, and more particularly, to techniques for reducing errors in queuing delay estimation caused by a clock skew, thereby providing improved data transmission control.
2. Discussion of Related Art
A computer network may include several computing devices for exchanging data through a communication path. In such a computer network, a computing device, when transmitting data to another computing device, may perform data transmission control based on a queuing delay involved in the data transmission. For example, in a network environment in which a data packet is transmitted via a router on a communication path, a queuing delay may be defined as a length of time during which the data packet waits in a buffer of the router. When the communication path suffers from network congestion (for example, the number of data packets flowing into the router per unit of time exceeds a throughput of the router), a data packet would wait in the buffer of the router until preceding data packets are processed by the router, even if the data packet has arrived at the router.
A TCP-Vegas technique, which is one of approaches of estimating the queuing delay, uses a round trip time (RTT) of a packet between a computing device that transmits data (hereinafter referred to as a “transmitter”) and a computing device that receives the data (hereinafter referred to as a “receiver”). Specifically, the RTT between the transmitter and the receiver represents the time it takes for the transmitter to send a packet to the receiver and receive, from the receiver, a response to the packet. For example, when the transmitter and the receiver are deployed in the above-mentioned network environment, the RTT between the transmitter and the receiver is the sum of (i) a first length of time for a packet to travel from the transmitter to the router, (ii) a second length of time for the packet to move from the router to the receiver, (iii) a third length of time for a response to the packet to traverse from the receiver to the router, (iv) a fourth length of time for the response to pass from the router to the transmitter, and (v) a queuing delay in the buffer of the router. Since it is generally noted that the first to fourth lengths of time are fixed, a change in the RTT can be regarded as a change in the queuing delay. Accordingly, it is reasonable to estimate the queuing delay at a certain time point as a measured value of the RTT at the time point, minus a value of the RTT measured when the queuing delay is 0 (hereinafter denoted as “baseRTT”).
Although, in fact, the queuing delay may be zero at a time point, it is unlikely to have direct knowledge of the time point. For example, in the above-mentioned network environment, it is rare that the transmitter and the receiver directly learn how full the buffer of the router is. Therefore, it is of great importance to estimate baseRTT prior to the estimation of the queuing delay. According to the TCP-Vegas technique, for a certain time t=k, RTTmin(0, k) is used as an estimate of baseRTT, where RTTmin(0, k) is a minimum value among the RTT values measured from t=0, which is a starting time point for the RTT measurement, to t=k. In other words, when the RTT measured at t=k is denoted as RTT(k), an estimate of the queuing delay for t=k is RTT(k) minus RTTmin(0, k). For example, RTTmin(0, k) may have a value of a variable RTTmin, which is updated at t=k, as follows. For t=0, RTTmin is set to RTT(0). Then, for t=k, when the RTT measurement at t=k is immediately preceded by the RTT measurement at t=j, the RTTmin value is changed to RTT(k) if RTT(k) is smaller than the value of RTTmin at t=j, and otherwise remains unchanged.
Alternatively, with a view to efficient operation of a computer network, the transmission control may be performed using a queuing delay on a forward path from a transmitter to a receiver (hereinafter referred to as a “forward queuing delay”). Such transmission control does not take into account a queuing delay on a backward path from the receiver to the transmitter (hereinafter referred to as a “backward queuing delay”), since the backward queuing delay is not associated with network congestion occurring on the forward path. For example, when the transmitter and the receiver are deployed in the above-mentioned network environment, the RTT between the transmitter and the receiver includes a length of time for a packet transmitted from the transmitter to the receiver to wait in the buffer of the router (that is, the forward queuing delay) and also includes a length of time for a response to the packet to wait in the buffer of the router in the course of traveling from the receiver to the transmitter (that is, the backward queuing delay). If network congestion occurs on the backward path and does not on the forward path, the transmission control need not be performed in a manner that reduces the transmission rate by reason of the backward queuing delay.
The forward queuing delay may be calculated using a one-way transmit time (OTT) on the forward path (hereinafter referred to as a “forward OTT”). The forward OTT is the time required for a packet to move from the transmitter to the receiver through the forward path, i.e., the time from when the packet departs from the transmitter to when the packet arrives at the receiver. In a manner similar to that for the estimation of baseRTT, OTTfmin(0, k) may be used as an estimate of the forward OTT value that would be measured when the queuing delay is 0 (hereinafter referred to “baseOTTf”), where OTTfmin (0, k) is a minimum value among the forward OTT values measured from t=0, a starting time point for the forward OTT measurement, to t=k. Accordingly, when the forward OTT measured at t=k is denoted as OTTf(k), an estimate of the forward queuing delay for t=k is OTTf(k) minus OTTfmin(0, k). For example, OTTfmin(0, k) may have a value of a variable OTTmin, which is a variable updated at t=k, as follows. For t=0, OTTfmin is set to OTTf(0). Then, for t=k, when the OTT measurement at t=k is immediately preceded by the OTT measurement at t=j, the OTTfmin value is changed to OTTf(k) if OTTf(k) is smaller than the value of OTTfmin at t=j, and otherwise remains unchanged.
When the transmitter and the receiver have different clocks, however, the forward OTT measurement involves calculating a time difference between time points measured with the different clocks (e.g., a packet departure time point measured with on a CPU clock of the transmitter and a packet arrival time point measured with a CPU clock of the receiver). One of the major causes of errors in the forward OTT measurement is a clock skew between the clock of the transmitter and the clock of the receiver. The clock skew represents a difference between a rate of increase in local time of the transmitter and a rate of increase in local time of the receiver. For example, even if the operating rate of the clock of the transmitter is slightly different from that of the clock of the receiver, there is a real difference between the increment in local time of the transmitter and the increment in local time of the receiver. Accordingly, with two local time points being respectively represented by the clock of the transmitter and the clock the receiver at a globally identical time point, the gap between the local time points grows larger with the lapse of global time. For example, if the queuing delay is 0 at certain two time points, each of the OTTf values measured at the two time points (i.e., baseOTTf) is different due to the clock skew. Such difference may cause a significant error in the forward OTT measurement.
An estimate of the forward queuing delay would not be valid if an OTT measurement error arises from the clock skew. In particular, when the computer network is used for a real time application such as Voice-over-IP or Video-over-IP, the incorrectly estimated value of the forward queuing delay may hamper the task of fulfilling a service quality demand of the application.